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Abstract. The existence of errors or inconsistencies in 
the configuration of security components, such as filtering 
routers and/or firewalls, may lead to weak access control 
policies — potentially easy to be evaded by unauthorized 
parties. We present in this paper a proposal to create, man- 
age, and deploy consistent policies in those components 
in an efficient way. To do so, we combine two main ap- 
proaches. The first approach is the use of an aggregation 
mechanism that yields consistent configurations or signals 
inconsistencies. Through this mechanism we can fold ex- 
isting policies of a given system and create a consistent and 
global set of access control rules — easy to maintain and 
manage by using a single syntax. The second approach 
is the use of a refinement mechanism that guarantees the 
proper deployment of such a global set of rules into the sys- 
tem, yet free of inconsistencies. 

1 Introduction 

In order to defend the resources of an information system 
against unauthorized actions, a security policy must be de- 
fined by the administrator of an information system, i.e. a 
set of rules stating what is permitted and what is prohib- 
ited in a system during normal operations. Once specified 
the complete set of prohibitions and permissions, the ad- 
ministrator must decide which security mechanisms to use 
in order to enforce the security policy. This enforcement 
consists in distributing the security rules expressed in this 
policy over different security components, such as filtering 
routers and firewalls. This implies cohesion of the security 
functions supplied by these components. Indeed, security 
rules deployed over different components must be consis- 
tent, addressing the same decisions under equivalent condi- 
tions, and not repeating the same actions more than once. 

A first solution to ensure these requirements is by ap- 
plying a formal security model to express network security 
policies. In ATI , for example, an access control language 



based on XML syntax and supported by the access control 
model Or-BAC [ 1 1 is proposed for specifying access control 
meta-rules and, then, refined into different firewall configu- 
ration rules through XSLT transformations. In fl4l . another 
top-down proposal based on the RBAC model ifTTl is also 
suggested for such a purpose. However, and although the 
use of formal models ensures cohesion, completeness and 
optimization as built-in properties, in most cases, adminis- 
trators are usually reluctant to define a whole security policy 
from scratch, and they expect to recycle existing configura- 
tions previously deployed over a given system. 

A second solution to guarantee consistent and non- 
redundant firewall configurations consists in analyzing and 
fixing rules already deployed. In fl3l , for example, a tax- 
onomy of conflicts in security policies is presented, and two 
main categories are proposed: (1) intra-firewall anomalies, 
which refer to those conflicts that might exist within the lo- 
cal set of rules of a given firewall; (2) inter-firewall anoma- 
lies, which refer to those conflicts that might exist between 
the configuration rules of different firewalls that match the 
same traffic. The authors in lfl3ll propose, moreover, an au- 
dit mechanism in order to discover and warn about these 
anomalies. In ElO, we pointed out to some existing limi- 
tations in [ 1 3 ] , and presented an alternative set of anomalies 
and audit algorithms that detect, report, and eliminate those 
intra- and inter-component inconsistencies existing on dis- 
tributed security setups — where both firewalls and NIDSs 
are in charge of the network security policy. 

The main drawback of the first solution, i.e., refinement 
processes such as IfTTl [Pfl . relies on the necessity of for- 
mally writing a global security policy from scratch, as well 
as a deep knowledge of a given formal model. This rea- 
son might explain why this solution is not yet widely used, 
and most of the times policies are simply deployed based 
on the expertise and flair of security administrators. The 
main drawback of the second solution, i.e., audit processes 
such as 1T31 12] for analyzing local and distributed security 
setups, relies on the lack of knowledge about the deployed 



policy from a global point of view — which is very helpful 
for maintenance and troubleshooting tasks. 

In this paper we propose to combine both solutions to 
better guarantee the requirements specified for a given net- 
work access control policy. Our procedure consists of two 
main steps. In the first step, the complete set of local poli- 
cies — already deployed over each firewall of a given sys- 
tem — are aggregated, and a global security policy is de- 
rived. It is then possible to update, analyze, and redeploy 
such a global security policy into several local policies — 
yet free of anomalies — in a further second step. We need, 
moreover, a previous step for retrieving all those details of 
the system's topology which might be necessary during the 
aggregation and deployment processes (cf. Section[2]i. The 
use of automatic network tools, such as lPT8l . may allow 
us to automatically generate this information, and properly 
manage any change within the system. 

The rest of this paper has been organized as follows. We 
first present in Section [2] the formalism we use to specify 
filtering rules, an the network model we use to represent 
the topology of the system. We describe in Section [3] our 
mechanisms to aggregate and deploy firewall configuration 
rules, and prove the correctness of such mechanisms. We 
present some related work in Section|4] and close the paper 
in Section|5]with some conclusions and future work. 

2 Rules, Topology and Anomalies 

We recall in this section some of the definitions previously 
introduced in [2] [3] . We first define a filtering rule in the 
form Ri : {cndi} — > decision^, where i is the relative posi- 
tion of the rule within the set of rules, decision is a boolean 
expression in {accept, deny}, and {cndi} is a conjunctive 
set of condition attributes (protocol, source, destination, 
and so on), such that {cndi} equals A\ A A2 A ... A A p , 
and p is the number of condition attributes of a given filter- 
ing rule. 

We define now a set of functions to determine which fire- 
walls of the system are crossed by a given packet know- 
ing its source and destination. Let F be a set of fire- 
walls and let Z be a set of zones. We assume that each 
pair of zones in Z are mutually disjoint, i.e., if Zi G Z 
and Zj G Z then Zi fl Zj — 0. We define the predicates 
connected(fi, $2) (which becomes true whether there ex- 
ists, at least, one interface connecting firewall fx to firewall 
^2) and adjacent(f, z) (which becomes true whether the 
zone z is interfaced to firewall /). We then define a set of 
paths, P, as follows. If / G F then [/] G P is an atomic 
path. Similarly, if [p.fi] G P (be "." a concatenation func- 
tor) and fc G F, such that f2 ^ P and connected^ \, J '2), 
then Ip.f1.f2] G P. Let us now define functions first, last, 
and tail from P in F such that if p is a path, then first(p) 
corresponds to the first firewall in the path, last(p) corre- 



sponds to the last firewall in the path, and tail(f,p) corre- 
sponds to rest of firewalls in the path after firewall /. We 
also define the order functor between paths as pi < p 2 , such 
that path pi is shorter than p 2 , and where all the firewalls 
within pi are also within p 2 . We define functions route 
such that p G route{z\, Z2) iff path p connects zone zi to 
zone z%, i.e., p G route(zi, Z2) iff adjacent(first(p), z\) 
and adjacent(last(p), Z2)', and minimal-route (or MR 
for short), such that p G MR(zx, z%) iff the following con- 
ditions hold: (1) p G routeizi, Z2)', (2) there does not exist 
p' G route{z\, Z2) such thatp' < p. 

Let us finally close this section by overviewing the 
complete set of anomalies defined in our previous work 
00: 

Intra-flrewall anomalies 

• Shadowing - A configuration rule R t is shadowed in 
a set of configuration rules R whether such a rule never 
applies because all the packets that Ri may match, are 
previously matched by another rule, or combination of 
rules, with higher priority. 

• Redundancy - A configuration rule Ri is redundant 
in a set of configuration rules R whether the following 
conditions hold: (1) Ri is not shadowed by any other 
rule or set of rules; (2) when removing Ri from R, the 
security policy does not change. 

Inter-firewall anomalies 

• Irrelevance - A configuration rule Ri is irrelevant in 
a set of configuration rules R if one of the following 
conditions holds: (1) Both source and destination ad- 
dress are within the same zone; (2) The firewall is not 
within the minimal route that connects the source zone 
to the destination zone. 

• Full/Partial-redundancy - A redundancy anomaljQ 
occurs between two firewalls whether the firewall clos- 
est to the destination zone blocks (completely or par- 
tially) traffic that is already blocked by the first fire- 
wall. 

• Full/Partial-shadowing - A shadowing anomaly oc- 
curs between two firewalls whether the one closest to 
the destination zone does not block traffic that is al- 
ready blocked by the first firewall. 

• Full/Partial-misconnection - A misconnection a- 
nomaly occurs between two firewalls whether the clos- 
est firewall to the source zone allows all the traffic — 
or just a part of it — that is denied by the second one. 

'Although this kind of redundancy is sometimes expressly introduced 
by network administrators (e.g., to guarantee the forbidden traffic will not 
reach the destination), it is important to report it since, if such a rule is 
applied, we may conclude that at least one of the redundant components is 
wrongly working. 



3 Proposed Mechanisms 



Algorithm 1: aggregation^) 



The objective of our proposal is the following. From a set F 
of firewalls initially deployed over a set Z of zones, and if 
neither intra- nor inter-firewall anomalies apply over such a 
setup, we aim to derive a single global security police setup 
R, also free of anomalies. Then, this set of rules R can be 
maintained and updatecd as a whole, as well as redeployed 
over the system through a further refinement process. We 
present in the following the main processes of our proposal. 

3.1 Aggregation of Policies 

Our aggregation mechanism works as follows. During an 
initial step (not covered in this paper) it gathers all those de- 
tails of the system's topology which might be necessary dur- 
ing the rest of stages. The use of network tools, such as |18|, 
allows us to properly manage this information, like the set F 
of firewalls, the set of configurations rules f [rules] of each 
firewall / e F, the set Z of zones of the system, and some 
other topological details defined in Section |2] An analy- 
sis of intra-firewall anomalies is then performed within the 
first stage of the aggregation process, in order to discover 
and fix any possible anomaly within the local configuration 
of each firewall f £ F. In the next step, an analysis of 
inter-firewall anomalies is performed at the same time that 
the aggregation of polices into R also does. If an anomaly 
within the initial setup is discovered, then an aggregation 
error warns the officer and the process quits. Conversely, if 
no inter-firewall anomalies are found, then a global set of 
rules R is generated and so returned as a result of the whole 
aggregation process. 

We present in Algorithm 1 our proposed aggregation 
process. The input data is a set F of firewalls whose con- 
figurations we want to fold into a global set of rules R. For 
reasons of clarity, we assume in our algorithm that one can 
access the elements of a set as a linked-list through the op- 
erator elementi. We also assume one can add new values 
to the list as any other normal variable does (elementi <— 
value), as well as to both remove and initialize elements 
through the addition of an empty set (elementi <— 0). The 
internal order of elements from the linked-list, moreover, 
keeps with the relative ordering of elements. 

The aggregation process consists of two main phases. 
During the first phase (cf. lines 2 and 3 of Algorithm 1), and 
through an iterative call to the auxiliary function policy- 
rewriting (cf. Algorithm 4), it analyzes the complete set F 
of firewalls, in order to discover and remove any possible 
intra-firewall anomaly. Thus, after this first stage, no use- 
less rules in the local configuration of any firewall f £ F 
might exist. We refer to Section 13.21 for a more detailed 
description of this function. 



1 /*Phase 1*/ 

2 foreach fx e F do 

3 I policy-rewriting (fi[rules\)\ 

4 / *Phase 2 * / 

5 R <- 0; 

6 i <- 0; 

7 foreach /i e F do 

foreach n G fi [rules] do 

9 Z s <- {z e Z | z n source (n) ^ 0}; 

10 Z d «- {z e Z I z n destination (n) ^ 0}; 

11 foreach z\ e Z s do 

12 foreach z 2 e Z d do 

13 if (zi = z 2 ) or(fi £ mr(zi , z 2 )) then 

14 aggregationError (); 
is return 0; 

16 else if ( r\ [decision] — "accept ") then 

n foreach / 2 e mr(«i, z 2 ) do 

18 f 2 rd <- 0; 

19 f 2 rd <— {r 2 £ fi \ r\ ^ ti A 

20 T2 [decision] — "deny' 1 }; 

21 if f-iempty(/2rd) y ) then 

22 aggregationError (); 

23 return 0; 

24 else 

25 f 2 ra <- 0; 

26 fzra <— {r 2 G /a | 71 ^ r 2 A 

27 r 2 \decision\ —''accepf'}; 

foreach r 2 G far a do 



28 
29 
30 
31 

32 
33 



34 

35 

36 
37 

38 
39 
40 
41 
42 
43 
44 
45 
46 

47 
48 
49 



Ri[source] <— z\\ 
Ri[destination] * 
i<-(i+l); 



22; 



else iff/i =first(MRf«i,a a j;j then 
hr 0; 

foreach / 3 e taii(/i,MR(zi,z 2 )) do 

[_ f3T <- {r 3 E f 3 \ri r 3 } U f 3 r; 

if (^empty(/ 3 r)j then 

aggregationError (); 
return 0; 

else 

Ri <- Ri U n; 
Resource] <— z±; 
Ri[destination] <— z 2 \ 
i*-(t + l); 
ri ^0; 



else 



aggregationError (); 
return 0; 



50 policy-rewriting (i?); 
si return i?; 



"These operations are not covered in the paper. 



During the second phase (cf. lines 5-51 of Algorithm 1), 
the aggregation of firewall configurations is performed as 
follows. For each permission configured in a firewall / G 
F, the process folds the whole chaiqjof permissions within 
the components on the minimal route from the source zone 
to the destination zone; and for each prohibition, it directly 
keeps such a rule, assuming it becomes to the closest fire- 
wall to the source, and no more prohibitions should be 
placed on the minimal route from the source zone to the 
destination zone. Moreover, and while the aggregation of 
policies is being performed, an analysis of inter-firewall 
anomalies is also applied in parallel. Then, if any inter- 
firewall anomaly is detected during the aggregation of rules 
R <— aggregation(F), a message of error is raised and the 
process quits. 

Let us for example assume that during the aggregation 
process, a filtering rule G ferules] presents an inter- 
firewall irrelevance, i.e., r, is a rule that applies to a source 
zone z\ and a destination zone z 2 (such that s = z% PI 
source(ri) ^ 0, d = z 2 f~l destination(ri) ^ 0) and either 
z\ and Z2 are the same zone, or firewall fi is not in the path 
/2, fk] € MR{z\, z 2 ). In this case, we can observe 
that during the folding process specified by Algorithm 1, the 
statement of line 13, i.e., (z\ = z 2 ) or (fi ^ MR(zi, z 2 )), 
becomes true and, then, the aggregation process finishes 
with an error and returns an empty set of rules (cf. state- 
ments of lines 14 and 15). Similarly, let us assume that 
r i £ fi[rules] presents an inter-firewall redundancy, i.e., 
ri is a prohibition that applies to a source zone z\ and a 
destination zone z 2 (such that s = zy PI source(ri) ^ 0, 
d = z 2 n destination(ri) ^ 0, and [fy, f 2 , ■ fk] £ 
MR(zy, z 2 )) and firewall fi is not the first component in 
MR(zy, z 2 ). In this case, we can observe that during the 
folding process specified by Algorithm 1, the statement of 
line 34, i.e., fi — first(MR(zy, z 2 )), becomes false and, 
then, the aggregating process finishes with an error and re- 
turns an empty set of rules. 

Let us now assume that G ferules] presents an inter- 
firewall shadowing, i.e., is a permission that applies to 
a source zone z\ and a destination zone z 2 such that there 
exists an equivalent prohibition rj that belongs to a fire- 
wall fj which, in turn, is closer to the source zone z\ in 
MR(zy, z 2 ). In this case, we can observe that during the 
folding process specified by Algorithm 1, the statement of 
line 38 detects that, after a prohibition in the first firewall 
of MR(z\, z 2 ), i.e., fj = first(MR(zy,z 2 )), there is, at 
least, a permission ri that correlates the same attributes. 
Then, the aggregating process finishes with an error and 
returns an empty set of rules. Let us finally assume that 
r i S /j [rwZes] presents an inter-firewall misconnection, i.e., 

3 The operator "W is used within Algorithm 1 to denote that two rules 
ri and rj are correlated if every attribute in ri has a non empty intersection 
with the corresponding attribute in rj . 



ri is a prohibition that applies to a source zone Zy and a des- 
tination zone z 2 such that there exists, at least, a permission 
Tj that belongs to a firewall fj closer to the source zone z\ 
in MR(zi, z 2 ). In this case, we can observe that during the 
folding process specified by Algorithm 1, the statement of 
line 21 detects this anomaly and, then, the process finishes 
with an error and returns an empty set of rules. 

It is straightforward then to conclude that whether no 
inter-firewall anomalies apply to any firewall / G F, our 
aggregation process returns a global set of filtering rules R 
with the union of all the filtering rules previously deployed 
over F. It is yet necessary to perform a post-process of 
R, in order to avoid the redundancy of all permissions, i.e., 
accept rules, gathered during the aggregating process. In 
order to do so, the aggregation process calls at the end of 
the second phase (cf. line 50 of Algorithm 1) to the auxil- 
iary function policy-rewriting (cf. Algorithm 4). We offer 
in the following a more detailed description of this function. 

3.2 Policy Rewriting 

We recall in this section our audit process to discover and 
remove rules that never apply or are redundant in local fire- 
wall policies (|9][10). The process is based on the analysis 
of relationships between the set of configuration rules of a 
local policy. Through a rewriting of rules, it derives from an 
initial set R to an equivalent one Tr(R) completely free of 
dependencies between attributes, i.e., without either redun- 
dant or shadowed rules. The whole process is split in three 
main functions (cf. algorithms 2, 3 and 4). 

The first function, exclusion (cf. Algorithm 2), is an 
auxiliary process which performs the exclusion of attributes 
between two rules. It receives as input two rules, A 
and B, and returns a third rule, C, whose set of con- 
dition attributes is the exclusion of the set of conditions 
from A over B. We represent the attributes of each rule 
in the form of i?u/e[cn<f@ as a boolean expression over 
p possible attributes (such as source, destination, proto- 
col, ports, and so on). Similarly, we represent the deci- 
sion of the rule in the form Rule[decision] as a boolean 
variable whose values are in {accept, deny}. Moreover, 
we use two extra elements for each rule, in the form 
Rule[shadowing] and Rule[redundancy], as two boolean 
variables in {true, false] to store the reason for why a rule 
may disappear during the process. 

The second function, test Redundancy (cf. Algo- 
rithm 3), is a boolean function in {true, false} which, 
in turn, applies the transformation exclusion (cf. Algo- 
rithm 2) over a set of configuration rules to check whether 
the first rule is redundant, i.e., applies the same policy, re- 
garding the rest of rules. 

4 We use the notation Ai and £?; as an abbreviation of both A [end] [i] 
and B[cnd][i] during the statements of lines 6-12. 



Finally, the third function, policy-rewriting (cf. Algo- 
rithm 4), performs the whole process of detecting and re- 
moving the complete set of intra-firewall anomalies. It re- 
ceives as input a set R of rules, and performs the audit pro- 
cess in two different phases. 

Algorithm 2: exclusion(£>,A) 

1 C[cnd] ~ 0; 

2 C[decision] *— B[decision]; 

3 C[shadowing] *— false; 

4 C [redundancy] <— false; 

5 forall the elements of A [end] and B[cnd] do 
if {{Ax n Bi) + and {A 2 n B 2 ) ^ and ... and 
{A p n B p ) ^ 0) then 

C[cnd] <~ C[cnd] U 
{(Bi — A\) ABaA ... A B v , 
(A! n Bi) A (B 2 - A 2 ) A ... A Bp, 
(A 1 n B x ) A (A 2 n B 2 ) A (B 3 - A3) A ... A Bp, 



(Ai n Bi) A ... A (Ap_i n Bp_i) A (Bp - Ap)}; 



else 



|_ C[cnd] <- (C[cnd] U B[cnd]); 
is return C; 



Algorithm 3: testRedundancy(i?,r) 

1 i <- 1; 

2 temp <— r; 

3 while -itesi and fi < count{R)) do 
4 
5 

6 



temp <— exclusion(iemp, 
if te77ip[cri<i] = then 
|^ return ir-ue; 

8 return false; 



During the first phase, any possible shadowing between 
rules with different decision values is marked and removed 
by iteratively applying function exclusion (cf. Algo- 
rithm 2). The resulting set of rules obtained after the ex- 
ecution of the first phase is again analyzed when applying 
the second phase. 

Each rule is first analyzed, through a call to function 
test Redundancy (cf. Algorithm 3), to those rules written 
after the checked rule but that can apply the same decision 
to the same traffic. If such a test of redundancy becomes 
true, the rule is marked as redundant and then removed. 
Otherwise, its attributes are then excluded from the rest of 
equivalent rules but with less priority in the order. In this 
way, if any shadowing between rules with the same deci- 
sion remained undetected during the first phase, it is then 
marked and removed. 



Algorithm 4: policy-rewriting(i?) 

in*— count{R); 

2 /*Phase 1*/ 

3 for i *— 1 to (n — 1) do 
for j *— (i + 1) to n do 

if Ri [decision] 7^ Rj[decision] then 



Ri 



exclusion (Rj,Ri); 



if Rj [end] = then 

Rj [shadowing] <— true; 



9 /*Phase 2*/ 

10 for i <— 1 to (n — 1) do 

11 R a <— {rk e R \ n > k > i and 

12 rk[decision] = ri[decision]}; 

13 if testRedundancy (R a ,Ri) then 

14 R t [cnd]^%; 

is Ri[redundancy] <— true; 

16 else 

17 for j <— {i + 1) to n do 

18 if Ri[ decision ]=Rj [decision ] then 

19 Rj *— exclusion (Rj,Ri); 

20 if f ->Rj [redundancy] and 

21 Rj [end] = 0J then 

22 Rj [shadowing] <— true; 



Based on the processes defined in algorithms 2, 3, and 4, 
we can prov^l the following theorem: 

Theorem 1 Let R be a set of filtering rules and let 
Tr(R) be the resulting filtering rules obtained by applying 
Algorithm 4 to R. Then the following statements hold: (1) 
R and Tr{R) are equivalent; (2) Ordering the rules in 
Tr(R) is no longer relevant; (3) Tr(R) is free from both 
shadowing and redundancy. 



3.3 Deployment of Rules 

We finally present in Algorithm 5 our proposed refinement 
mechanism for the deployment of an updated global set of 
rules. The deployment strategy defined in the algorithm is 
the following. Let F be the set of firewalls that partitions 
the system into the set Z of zones. Let R be the set of con- 
figuration rules resulting from the maintenance of a given 
global set of rules obtained from the aggregation process 
presented in Section |3~TI (cf. Algorithm 1). Let r G R be 
a configuration rule that applies to a source zone z\ and a 



5 A set of proofs to validate Theorem 1, as well as a complexity analysis 
of function policy-rewriting (cf. Algorithm 4) and its performance in a 
research prototype, is provided in (9). 



destination zone z 2 , such that s = Z\ fl source(r) ^ and 
d = z 2 H destination(r) ^ 0. Let r' be a rule identical to r 
except that source(r') — s and destination(r') = d. Let 
us finally assume that [fi, fz, . • . , fk] G MR(zi, zs)- Then, 
any rule r G i? is deployed over the system as follows: 

• If r[decision] = accept then deploy a permission r' 
on every firewall on the minimal route from source s 
to destination d. 

• If r[decision] = deny then deploy a sing prohibi- 
tion r' on the most-upstream firewall (i.e., the closest 
firewall to the source) of the minimal route from source 
s to destination d. If such a firewall does not exist, then 
generate a deployment error message. 



rules in R is not relevant. On the other hand, the use of 
the deployment strategy defined above allows us to guaran- 
tee that the resulting setup is free of inter-firewall anoma- 
lies. First, since each permission r a in R opens a flow of 
permissions over all the firewalls within the minimal routes 
from the source to the destination pointed by r a , and since 
any other rule r' in R cannot match the same traffic that r a 
matches, we can guarantee that neither inter-firewall shad- 
owing nor inter-firewall misconnection can appear in the 
resulting setup. Second, since each prohibition r^ in R 
is deployed just once in the closest firewall to the source 
pointed by r<j, and since any other rule r' in R cannot match 
the same traffic that r^ matches, we can guarantee that any 
inter-firewall redundancy can appear in the resulting setup. 



Algorithm 5: deployment(i?,Z) 



1 policy-rewriting (R); 

2 foreach n G R do 



3 
4 
5 
6 
7 
8 
9 
10 
11 
12 

13 
14 
15 
16 
17 
18 
19 
20 
21 
22 



Z s <— {z G Z | z (~1 source (r{) ^ 0}; 
Zd *— {z G Z | z n destination (r{) ^ 0}; 
foreach z\ G Z s do 
foreach z 2 G Z d do 

if r\ [decision] = "accept" then 
foreach /i g MR(zi, z 2 ) do 



' i 



r; 



7N \ source\ 



r ^[destination] <— Z 2 ; 
/i[ndes] <— /i[ru/es] Ur'; 

else if r*i [decision] = "deny" then 
/i <- first(MR(zi,z 2 )); 
if f^empty then 

^[source] <— Z\\ 
^[destination] <— Z 2 ; 
/i[ruies] <— /i[ru/es] Ur'; 



else 



deploymentError (); 
exit (); 



It is straightforward now to prove that the deployment of 
a given set of rules R through Algorithm 5 is free of either 
intra- and/or inter-firewall anomalies (cf. Section|2). On the 
one hand, during the earliest stage of Algorithm 5, the com- 
plete set of rules in R is analyzed and, if necessary, fixed 
with our policy-rewriting process (cf. Section 13721 Algo- 
rithm 4). Then, by TheoremQ] we can guarantee that nei- 
ther shadowed nor redundant rules might exist in R. More- 
over, it also allows us to guarantee that the order between 



6 This decision is a choice for avoiding inter-firewall redundancy in the 
resulting setup. 



4 Related Work 

A first solution to deploy access control policies free of 
errors is by applying a refinement mechanism. Hence, 
following such a top-down mechanism, one can deploy a 
global security policy into several component's configura- 
tions lfTTl|6l[T4l 

In [11], for example, a formal approach based on the Or- 
BAC model [ 1 1 is presented for this purpose. There, a set of 
filtering rules, whose syntax is specific to a given firewall, 
may be generated using a transformation process. The au- 
thors in [ 6 ] , on the other hand, use the concept of roles to de- 
fine network capabilities and refinement of policies. Indeed, 
they propose the use of an inheritance mechanism through a 
hierarchy of entities to automatically generate permissions. 

However, their work does not fix, from our point of view, 
clear semantics, and their concept of role becomes ambigu- 
ous as we pointed out in [ 1 1 ] . Another work based on policy 
refinement is the RBNS model [ 14 1. However, and although 
the authors claim that their work is based on the RBAC 
model ifTTl . it seems that they only keep from this model 
only the concept of role. Indeed, the specification of net- 
work entities and role and permission assignments are not 
rigorous and does not fit any reality ifTTI . 

The use of these refinement proposals |[TTl l6i ri4ll ensures 
cohesion, completeness and optimization as built-in proper- 
ties. However, it is not always enough to ensure that the 
firewall configuration is completely free of errors and, of- 
ten, administrators are reluctant to follow such a proposal. 
For this reason, we extended in this paper the approach pre- 
sented in [11], offering to administrators the possibility of 
aggregating existing configurations before moving to such 
a refinement approach. 

Support tools, on the other hand, are intended to di- 
rectly assist administrators in their task of configuring from 
scratch firewall configurations. Firewall Builder |fT51 , for 
example, provides a user interface to be used to specify a 
network access control policy and then this policy is auto- 



matically translated into various firewall configuration lan- 
guages such as NetFilter |19|, Ip Filter [16| or Cisco PIX 
181 . It also provides higher portability. For instance, if in a 
given network infrastructure, IpFilter is replaced by NetFil- 
ter, it will not be necessary to completely reconfigure Net- 
Filter. Firewall Builder will automatically generate the rules 
necessary to configure this firewall. 

However, we observed some problems when using Fi- 
werall Builder. First, we noticed that it might generate in- 
correct rules. In the case of NetFilter, for example, we ex- 
perienced the generation of rules associated to FORWARD 
when they should be associated to OUTPUT and INPUT 
chains. Second, we noticed the generation of redundant 
rules, although such redundancy was not specified within 
the policy. Third, it includes a mechanism called shadowing 
to detect redundancy in the policy. However, this shadow- 
ing mechanism only detects simple redundancy that corre- 
sponds to trivial equality or inclusion between zones. More 
complex redundancies (as the anomalies defined in Sec- 
tion|2]i are unfortunately not detected. 

Some other proposals, such as Ifl3l [20l [2] [3), provide 
means to directly manage the discovery of anomalies from 
a bottom-up approach. For instance, the authors in [ 13 1 pro- 
pose a set of algorithms to detect policy anomalies in both 
single- and multi-firewall configuration setups. In addition 
to the discovery process, their approach also attempts an 
optimal insertion of arbitrary rules into an existing config- 
uration, through a tree based representation of the filtering 
criteria. Nonetheless, we consider their approach as incom- 
plete. Their discovery approach is not complete since, given 
a single- or multiple-component security policy, their de- 
tection algorithms are based on the analysis of relationships 
between rules two by two. This way, errors due to the union 
of rules are not explicitly considered (as our approach pre- 
sented in J2]|3l does). 

Although in \4\ the authors pointed out to this problem- 
atic, claiming that they break down the initial set of rules 
into an equivalent set of rules free of overlaps between 
rules, no specific algorithms have been provided for solv- 
ing it. From our point of view, the proposal presented in 
1 20] best addresses such a problem, although it also presents 
some limitations. For instance, we can easily find situations 
where the proposal presented in l20l reports partial redun- 
dancies instead of a single full redundancy. Moreover, nei- 
ther lfl3l nor ll20l address, as we do in this paper by extend- 
ing the approach presented in J21 [TT], a folding process for 
combining both analysis and refinement strategies. 

5 Conclusions 

The existence of errors or anomalies in the configuration 
of network security components, such as filtering routers 
or firewalls, is very likely to degrade the security policy of a 



system [ 1 2 1 . This is a serious problem which must be solved 
since, if not handled correctly, it can lead to unauthorized 
parties to get the control of such a system. 

We introduced in Section Q] two main strategies to set 
firewall configurations free of errors. The first approach 
is to apply a formal security model — such as the formal 
model we presented in ifTTl — to express the security pol- 
icy of the access control for the network, and to generate the 
specific syntax for each given firewall from this formal pol- 
icy — for instance, by using XSLT transformations from 
the formal policy to generate specific Netfilter configura- 
tion rules 1 19 1 . A second approach is to apply an analysis 
process of existing configurations, in order to detect con- 
figuration errors and to properly eliminate them. In (2J|3), 
for instance, we presented an audit process based on this 
second strategy to set a distributed security scenario free of 
misconfiguration. 

We presented in Section [3] how to combine both ap- 
proaches in order to better guarantee the requirements spec- 
ified for a given network access control policy. Thus, from 
an initial bottom-up approach, we can analyze existing con- 
figurations already deployed into a given system, in order 
to detect and correct potential anomalies or configuration 
errors. Once verified those setups, we offer to the adminis- 
trator a folding mechanism to aggregate the different con- 
figurations into a global security policy to, finally, express 
by using a sole formal model, the security policy as a whole. 
The security officer can then perform maintenance tasks 
over such a single point, and then, unfold the changes into 
the existing security components of the system. 

As work in progress, we are actually evaluating the im- 
plementation of the strategy presented in this paper by com- 
bining both the refinement process presented in IfTTl and 
the audit mechanism presented in [2, 3| (both of them im- 
plemented through a scripting language as a web service 
Q). Although this first research prototype demonstrates the 
effectiveness of our approach, more evaluations should be 
done to study the real impact of our proposal for the main- 
tenance and deployment of complex production scenarios. 
We plan to address these evaluations and discuss the results 
in a forthcoming paper. 

On the other hand, and as future work, we are currently 
studying how to extend our approach in the case where the 
security architecture includes not only firewalls but also 
IDS/IPS, and IPSec devices. Though there is a real similar- 
ity between the parameters of those devices' rules (as we 
partially show in 12 O for the analysis of anomalies), more 
investigation has to be done in order to extend the approach 
presented in this paper. In parallel to this work, we are 
also considering to extend our approach to the managing of 
stateful policies. 
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